Release notes for version 3.24.0

If you have used a previous version of Neuron Power Engineer and you want to use the current version, see "Are my projects upwards and downwards compatible?" for important information. Recommended, if you are using projects that have been created in a previous version of Neuron Power Engineer: Clean the imported projects.

See "Is the IDE affected by the Log4j security vulnerability (December 2021, CVE-2021-44228, Log4Shell)".

See "Release notes for system libraries".

Depending on the configuration of your Neuron Power Engineer version, the FBD-editor and its elements might be displayed differently in your Neuron Power Engineer version than illustrated in the IDE documentation. This is the case, if Neuron  or the system integrator has activated the smart styling or one of them has changed the styles for the FBD-editor. Subsequently, the illustration in the IDE documentation are symbolic images and the representation in your Neuron Power Engineer version takes precedence for the valid representation. In case of doubts, please contact Neuron or your system integrator.

See "Color and style for FBD-elements determined by data type" for details.

With the positioning of the Neuron brand, there is a breaking change in this version:

• The product names have been changed to: “Neuron Power Engineer” (for the IDE) and “Neuron RTS max” (for the runtime system)

As a consequence, the following changes have been made:

• The file to start Neuron Power Engineer has changed to: NeuronPowerEngineer.exe
  This has the following consequences for you:

  • Double-click the file NeuronPowerEngineer.exe to start the IDE.

  • When you are using the headless tools, adjust the invocation of the headless tools to incorporate this new file name.
    Example for the new invocation of the automated importing of a project:

    NeuronPowerEngineerc --launcher.ini NeuronPowerEngineer.ini -application com.logicals.application.importer.application -noSplash -projectPath C:\LC3Projects\MyProject -data C:\temp\LC3Workspace -vmargs -Dlog4j.configuration=file:C:\LC3LogConfig\log4j.xml

• The path suggested for the workspace has changed to C:\Users\TheoTest\logi.cals\NeuronPowerEngineer\workspace

• The path for the library provider has changed to logi.cals\NeuronPowerEngineer\Libraries of the Windows user folder.
  

• The path for the library cache has changed to logi.cals\NeuronPowerEngineer\.libcache  of the Windows user folder.

The IDE documentation reflects all these changes. As a short name for the company, “Neuron” is used in the IDE documentation.

• When you start the new version of the IDE, Neuron strongly recommends you to use a new workspace when starting the IDE.
  The best practices is to use the path suggested for the workspace when starting Neuron Power Engineer. This is for example: C:\Users\TheoTest\logi.cals\NeuronPowerEngineer\workspace
  As a consequence, you have to import your projects into this new workspace.
  But, of course, it is still possible to use your workspace from the previous version. If you do, observe that the paths for the library provider and the library cache are the paths that have been specified in the previous version. The reason for this is that the path specifications for library provider and library cache are stored in the workspace.
  If you do accept the new workspace path that is suggested when starting the new version of IDE, there might be less confusion when you need to make changes that involve libraries, its library provider and library cache.

• If you do use an existing workspace and the error message Unable to create resource URLImageDescriptor(platform:/plugin/com.logicals.common.ui/resources/icons/application_navigator_tab_icon_16x16x32.png) is displayed, start the IDE from a command prompt with the option -clearPersistedState. See “Error when starting the development environment” for details.

When you declare a variable by using the command New Variable... in the list of declared variables visible, the behavior of the opened dialog has been changed as follows:

In case of missing or incorrect data for the variable, the respective field in the dialog is now highlighted with a red border and an error icon. When you move the mouse pointer over this error icon, a message details the error.
Missing data is a missing name or a missing data type. Incorrect data is an invalid name, an invalid data type, an invalid initial value (in the context of the specified data type) or an initial value for an external variable.

In previous versions, the button OK has been highlighted with an error icon and only a generic message has been displayed. The new error highlighting makes it easier for you to fix the error for the variable declaration.

If you are creating safety-relevant applications, keep in mind that calls of blocks are no longer automatically updated when you open the FBD-editor if the interface for the blocks has changed in the interface editor. However, you remain able to update a changed interface yourself by selecting the call and pressing Ctrl+1 or the F5-key.

You can find more details on the update under "Updating existing calls for changed interfaces".

When editing or debugging POUs in the FBD-editor, the IDE can open two different tabs of editing mode and debugging mode at the same time. This is the default behavior:

• The tab for debugging is started e.g. when double-clicking the instance/variable in the Instances view or using the context menu command Open Instance. See "Going to a function block or program and setting the instance context" for details on this command.

• The tab for editing is started e.g. when using the context menu command Open Type in Instances view. See "Going to instance or variable (without instance context)" for details on this command.

Now it is possible to change the default behavior so that just one tab is opened for editing and debugging POUs in the FBD-editor. If you are interested in this behavior, ask the system integrator to activate the new configuration variable -Dlc3.fbd.autoswitch_edit_diagnostic_view. Details on this configuration variable are provided in the English documentation "IDE administrator's manual" that is provided to the system integrators.

This possibility helps to avoid any synchronization issues between editing and debugging tabs. But mind that the closing and opening of the tabs might change the tab order.

The HTML-report that is generated when the application is built (also called build report) does now contain the information whether a task is defined as IO task. This information is displayed along with the other data for the program structure.

This new information is of particular interest when building safety-related applications.

The FBD-editor can now be used with 2 different stylings:

1. legacy styling
   This is the styling as known from the previous versions of Neuron Power Engineer. This is the default styling if you or the system integrator have not changed anything for your system.

2. smart styling
   This is an alternative to the legacy styling. Usually, the smart styling is activated by a system integrator because the configuration variable -Dlc3.editorstyle.smart.default must be defined.
   The main advantages of the smart styling are:

   • The FBD elements have a more modern display to create a more visually appealing appearance.

   • The appearance is less colorful while a clear visual differentiation of different data types is retained. As a consequence, it is easier to distinguish the safe and non-safe data types, function blocks, and functions.

   • The function blocks and functions provide more space to display the value of variables without having to place any OLT fields
     Also, value fields (containing a variable) automatically display the value of the variable on top of the value field, but value fields containing expressions or literals do not display the value. Consider this a variable value display that you cannot delete, move, or resize.

   • The variable value display is provided in the FBD-editor that is opened with an instance context. You can change the value of a variable by double-clicking the value and entering the new value in the dialog. This dialog is the usual dialog for changing the value of a variable.

   • You are still able to insert and use the OLT fields as known from legacy styling.

   • The smart styling supports a light theme as well as a dark theme. Both themes are provided in the preferences of Neuron Power Engineer (menu Windows, Preferences, group General, subgroup Appearance, select the appropriate theme under Theme).

See “Smart styling for the FBD-editor” for details and illustrations of how the FBD elements are displayed. All other illustrations with FBD elements in the user documentation use the legacy styling.

If the styling is changed, observe that the new styling is applied only to the newly created project. Already existing projects will not be affected by a changed styling. The chosen styling applies to all FBD-POUs in the project. It is not possible to mix legacy and smart styling within the same project.
Moreover, observe that copying and pasting FBD-elements between legacy and smart styling (or vice versa) might not correctly convert the pasted FBD-elements to the target style. In such a case, you must take care to adjust the pasted FBD-elements yourself.

Moreover, 2 new properties are provided for implementing vendor blocks. These properties are applied for the smart styling only. These properties are:

• smartWidth: This property is similar to the existing property width. Both properties width and smartWidth determine the width of the block when the block is inserted into an FBD-editor, with smartWidth taking precedence. The best practice is to use smartWidth for smart styling and width for legacy styling.

• safeStyle: This property is similar to the existing property bgColor but with a specified gold background color. The property safeStyle can be used if a block tracks safe signals when developing safety-related applications and the block should be displayed with this gold background color in the smart styling. Do not misuse the property safeStyle for other blocks because the color "Yellow" is used for tracking safe signals when developing safety-related applications. The misuse of the property safeStyle could have the consequence that the color "Gold" might also identify a non-safe logic as well.

See “Properties for implementing vendor blocks” for details on the properties for implementing vendor blocks.

You can create ST-classes, also identified just as “classes”. A class is a program organization unit (POU) consisting of:

• the definition of a data structure,

• a set of methods to be performed upon the data structure

A class is similar to a function block. See “Declaration of a class in ST“ on the ST-syntax of a class and the differences to a function block.

Observe that:

• A class cannot be dragged into an FBD-editor.

• It is possible to deploy a class in a library configuration by using the value “SOURCE” and “INTERFACE” but not with the value “OBJECT”.

Also, It is possible to deploy a function block with methods by using the value “SOURCE” and “INTERFACE”. Compare: In previous versions, it was possible to deploy function blocks with methods in a library configuration by using the value “SOURCE” only.

The Java Runtime used by Neuron Power Engineer has been updated to version 17.0.9 to fix a memory leak.
JRE is included in the delivery range of Neuron Power Engineer and is installed together with Neuron Power Engineer.

See “Why do I need JRE?” for more information why JRE is needed for Neuron Power Engineer.

The attribute SIZE has already been supported for directly derived data types. Now this attribute is also supported for a structured data type in ST.

Here the attribute SIZE can be added after the keyword END_STRUCT but before the character ;.

See the syntax under topic “Declaration of a structured data type with partial address in ST“ and “Declaration of a language element with partial address in ST“.

When you declare a structured data type in the ST-editor and specify the optional attribute OFFSET, the pragma is correctly considered by the size calculation. The calculation of a wrong structure size (as reported by the issue with the ID “108513“ does not occur anymore.

Here is an example to illustrate the calculation using OFFSET: The new calculated size is 33 bits (depending on the element S_ByteNext placed behind S_Bool). Whereas in previous versions, the calculated size has been 25 bits.

{KeepElementOrder}

  Motion_Out_DataSpeed_Type : STRUCT

    Ready : BYTE;

    S_Byte AT %M* { OFFSET := 20} : BYTE;

    S_Bool AT %M* { OFFSET := 24} : BOOL;

END_STRUCT;

More examples can be found in the topic “Declaration of a language element with partial address in ST“.

Now you open the safety parameter editor as follows:

1. Make the application navigator visible.

2. Expand a configuration in the application navigator.
   Result if the configuration contains a configuration of the safety-relevant hardware devices as parameters: The subfolder SafeNODEs becomes visible.

3. Also, expand SafeNODEs to make the item with the icon visible as well.

4. Open the context menu for this item and select the command Edit Safety Parameter. Alternative: Double-click this item.

In previous versions, the command was provided in the context menu for the configuration itself. In the current version, the configuration contains the new folder SafeNODEs to start the safety parameter editor.

Moreover, observe that the button Save all in the safety parameter editor is not provided anymore. Just use the button Save group that is still provided at the end of the group with the safety parameter editor.

The standard package of the IDE provides the new rule Limited variability languages (LVL) must be used only.

Use this rule to check whether the application uses elements that do not follow the guidelines for limited variability languages (→LVL).

As usual for rules, you can change the configuration of this rule.

Now, the application navigator displays the project blocks and global variables of the entire project. Observe that these elements are displayed under the folder Application.

Compare the behavior in previous versions:

1. The folder Project blocks only listed the POUs, interfaces, and data types when they were located under the folder src of the project.
   The application navigator of the new version does not provide the folder Project blocks anymore.

2. The folder Global variables only listed the global variables objects when they were located under the folder globals of the project.
   The application navigator of the new version does not provide the folder Global variables anymore.

For accessing IOs, mind that specified warnings/notes apply. See Properties and restrictions specific to the target system“, section Accessing IOs“ for details.

These warnings/notes are also included in the document “Safety instructions on working with the IDE” under “Warnings/notes for accessing IOs“ because they are relevant when you are developing a safety-related application.

The tab Properties of the interface editor provides the new setting Safe style.

Neuron recommends to use this safe style only if a block tracks safe signals when developing safety-related applications. Do not misuse this setting for other blocks.

See “Defining background color for the interface” for more information on the impact of this setting.

In the current IDE version, the PLCopen blocks are now based on the technical specification "TC5 - Safety, Version 2.10 – Official Release, Part 1 - Concepts and Function blocks" (© PLCopen). In the previous IDE version, the blocks were based on the version 2.01 of the technical specification.

Please observe that the description in the IDE documentation has not been updated to reflect this implementation change. The description will be updated in future versions.

In the meantime, if you need information on the changed behavior of the PLCopen blocks, please contact Neuron.

Declaring a namespace in the FBD-editor might cause errors in the FBD-editor.
Fix: The problem according to the following scenario does not occur in the current version anymore. Moreover, it is possible that this problem does not occur anymore in versions after V3.20.0
Scenario for problem: The following steps cause errors in the FBD-editor:

1. You declare an ST-function in a namespace.

2. You call this ST-function within an FBD-program.

3. You switch to the tab Namespaces in the FBD-editor for the program, enter a namespace for the FBD-program and press the Enter-key.
   Result: The call of the ST-function in the FBD-editor is highlighted as faulty. If you move the mouse pointer onto the error icon, the following message is displayed: Could not resolve reference to '_ST function_'. A function or function block instance with this name does not exist.

If you save the changes, the Problems view also displays this message and similar messages.

Formatting the PLC object might cause an error in the specifications for PARAMS. As a result, it is not possible to load the application onto the PLC.
Fix: The problem according to the following scenario does not occur anymore.
Scenario for problem: Depending on the used PLC, the PLC object may contain specifications for PARAMS that control the communication with the gateway.

{

  TARGET usRTSTarget_Win

    PARAMS := '{

      (* other data *)

      },

      "infrastructure" : {

       (* other data *) 

        "parameters" : {

          "programmerExec" : "<at:var at:name="PROGRAMMER" />",

          "programmerParam" : "<at:var at:name="FILENAME" /> C:\\temp\\RTSCode.upload.dll",

           (* other data *) 

        }

      }

    }';

  END_TARGET

}

If you format the code in the PLC object using the context menu command Source, Format or the keyboard shortcut Ctrl+Shift+F, the path specification after "programmerParam" is reformatted incorrectly, as spaces are inserted before and after the : character. So, the example C:\\tempRTSCode.upload.dll becomes: C : \\tempRTSCode.upload.dll
Due to this incorrect path, it is no longer possible to load the application to the PLC.

The fingerprint of the application is not updated in the "Instances" view when changing C-sources.
Fix: The fingerprint of the application is updated in the Instances view when changing C-sources.
Scenario for problem: When changing the contents of a C-file of a vendor block and saving this change, the fingerprint of the application is not updated in the Instances view.

Changed applications for PTK GCC 10.2.x may fail to build.
Fix: The problem according to the following scenario does not occur anymore.
Scenario for problem: Building the changed application with platform toolkits that use GCC 10.2.x may fail with the following message:

ninja: error: FindFirstFileExA(c/:/prj/bur/saturn/runtime-spdesigner/counter1/src-gen): The filename, directory name, or volume label syntax is incorrect.

Additional information: The problem occurs only if the platform toolkit does not contain the forceRebuild setting or the setting is set to FALSE.

The quick fix to resolve errors in the "Problems" view may not work.
Fix: The quick fix to resolve errors in the Problems view can be used now. If the quick fix cannot be applied, the following message in the error log informs you about the possible alternative: The quick fix is not available here. Use the quick fix or update commands provided in the context menu of the editor.
Scenario for problem: The context menu for messages in the Problems view may contain the command Quick Fix to perform a quick correction of the problem. In this case, a quick fix is not available:

1. You are inserting the call for an ST function block into an FBD-editor.

2. You insert a new input into the ST function block.
   Result: The call is highlighted as a warning. The warning in the Problems view contains the disabled command Quick Fix.

A test suite with a name that is too long cannot be exported to Excel.
Fix: The test suite can be exported because the IDE shortens the name that is too long. The following message informs you about this shortening: At least one testcase name is longer than 30 characters and has been automatically shortened for export.
Scenario for problem: By using the export wizard, it is possible to export a test suite to Excel. However, if the name of at least one testcase is longer than 30 characters, this export is not possible. In this case, the following messages are displayed in a dialog:

'Exporting test suite to Excel' has encountered a problem.

An internal error occurred during: 'Exporting test suite to Excel'

Cannot invoke 'org.osgi.framework.BundleContext.getBundle()' because the return value of 'com.logicals.lc3.api.common.BundleInformation.getBundleContext()' is null

The order of 2 illustrations in an article of the IDE documentation is wrong.
Fix: The article has been corrected in the IDE documentation so it contains the illustrations in the correct order.
Scenario for problem: The article "Inserting a call of a block or value field into existing lines" in the IDE documentation contains 2 illustrations in the last section that are in the wrong order.

The migration of constants may cause an error in the target project.
Fix: The problem according to the following scenario does not occur anymore.
Scenario for problem: If you migrate a project of the predecessor product and an FBD-editor contains a value field with the constant "1.0E-6", the graphical FBD-editor cannot be opened for the migrated object with the value field. The reason for this is a syntax error as the value field contains the wrong value _1.0E-6.

A dialog for saving the changes is displayed by mistake.
Fix: The problem according to the following scenario does not occur anymore.
Scenario for problem: If you change the content of an FBD-editor without saving yet, then disable the access rights for the group Application and save the change in the FBD-editor despite the disabled features (by using the button Save all), you receive the correct information that the content cannot be saved due to the missing permissions for the access control, but that it can be saved under a different name. If you select No here to not save the content, a dialog will be displayed by mistake offering to save the content of the FBD-editor, not to save the content or to cancel the saving action itself.
Additional information: The same problem may occur if you use a version with team server function.

The preview of the interface editor is not updated correctly when undoing the creation of a value field.
Fix: The problem according to the following scenario does not occur anymore.
Scenario for problem: When you create a value field within the interface editor (such value fields are also known as internal value fields), it seems that it is not possible to undo this creation. In fact, the created value field is deleted but the preview of the interface editor continues to display the value field. When selecting this value field in the preview, error messages are displayed within the error log.

It may not be possible to undo the creation of a comment field within the interface editor.
Fix: The problem according to the following scenario does not occur anymore.
Scenario for problem: If you create a comment field within the interface editor and cancel entering the text in the comment field by pressing the ESC-key, it is not possible to undo this creation.

The deletion of elements within the interface editor may need to be undone twice.
Fix: The undo action is only necessary once for the following scenario.
Scenario for problem: If you delete a value field, a comment field, or the instance name within the interface editor, and then want to undo this deletion, the deleted element is not restored. You must execute the undo action one more time for the deleted element to be restored.

An exception occurs when instance parameter are copied in a dialog.
Fix: The exception for the following scenario does not occur anymore.
Scenario for problem: When you copy the displayed instance parameter in a dilaog, an exception occurs. In this case, the following message is displayed in the error log.

com.logicals.iec.fbd.editor.shared
class com.logicals.iec.fbd.ui.editor.fxnode.GraphicElementsPaneImpl cannot be cast to class com.logicals.iec.fbd.editor.shared.fxnode.PagePane (com.logicals.iec.fbd.ui.editor.fxnode.GraphicElementsPaneImpl is in unnamed module of loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @415ef4d8; com.logicals.iec.fbd.editor.shared.fxnode.PagePane is in unnamed module of loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @3453acd2)

Additional information:

• Instance parameters are a part of instance data that are additional data elements for the function block.

• Usually, instance data elements exist only for function blocks within a library provided by a system integrator. If you want to display and/or enter instance data elements for a block within the graphical user interface of the IDE, you require an IDE variant that has been enhanced by a system integrator.

A STRING variable cannot be changed in the dialog.
Fix: The problem according to the following scenario does not occur anymore.
Scenario for problem: If a STRING variable is declared and you open the dialog for changing the name, data type and initial value of the declared variable (e.g. by double-clicking onto the variable in the list of declared variables), there is no entry for data type in the dialog. Therefore, it is not immediately possible to change the STRING variable. This is because the OK button is not available due to the missing data type.

Special characters within OLT fields are not evaluated as expected when debugging an application.
Fix: The dialog to change the values for a STRING variable is now providing 2 tabs Visual and Text. Use these tabs as follows:

• In the default tab Visual, enter the special characters by using the keyboard, such as umlauts (e.g. für) or several lines by pressing Shift+Enter.

• Switch to the tab Text to enter the desired three-character combination (e.g. $FCr or $0a for a line break). This tab Text does not support the input of the special characters by using the keyboard.

Scenario for problem: When debugging an application, if you enter special characters, such as umlauts or texts with several lines, using the three-character combination (starting with the dollar sign ($) and followed by 2 hexadecimal digits), the entry is not evaluated as the expected character.
Examples: The entry $0a is not evaluated as a new line. The entry f$FCr is not evaluated as "für".
Additional information: The field Initial value for a STRING variable displays this three-character combination in the list of the declared variables.

The initial value of declared variables might not be changed.
Fix: The problem according to the following scenario does not occur anymore.
Scenario for problem: If a variable is declared based on a structured data type, it is not possible to enter or change the initial value for this variable by clicking on the Initial value field in the list of the declared variables. It is also not possible to enter or change the initial value by using the command Edit Initial Value or Ctrl+I.

The application cannot be built if the characters * / are contained in a property field in FBD.
Fix: The problem according to the following scenario does not occur anymore.
Scenario for problem: The application cannot be built if the characters * / are contained in a property field in FBD. In this case, the following messages are displayed:

The application for the PLC (resource "name1", platform toolkit "name2") cannot be created/loaded. Check the views "Error Log" and "Problems" for more information.

An error occurred during compiling or linking the code image (error code: 1).

The application cannot be built if the characters */ are contained in a property field in ST.
Fix: The application can be built for the following scenario.
Scenario for problem: The application cannot be built if the characters */ are contained in a property statement in ST. In this case, the following messages are displayed:

The application for the PLC (resource "name1", platform toolkit "name2") cannot be created/loaded. Check the views "Error Log" and "Problems" for more information.

An error occurred during compiling or linking the code image (error code: 1).

A global-object can be renamed to an invalid name in the application navigator.
Fix: The IDE prevents the invalid name of the global-object even when it is renamed in the application navigator.
Scenario for problem: It is possible to rename a global-object in the application navigator so that the name contains an invalid character (e.g. umlauts) or corresponds to an already used name if the name uses upper/lower case letters differently. As a result, the renamed global-object is correctly reported as faulty.
Additional information: The IDE prevents the creation of a global-object if the name contains an invalid character or corresponds to an already used name (regardless of the use of upper/lower case letters in the name).

The call of a block can be enlarged, although this should not be possible.
Fix: The problem according to the following scenario does not occur anymore.
Scenario for problem: If the setting Fixed Size is checked within the interface editor, it is not possible to make a call of the block larger or smaller according to the IDE documentation. In reality, you can enlarge the call if you adjust the size of several FBD-elements in one go by using the commands Layout and Same Size. Reducing the size is not possible in this way, as mentioned in the IDE documentation.

Unexpected behavior of features in the case of the missing configuration variable -Dlc3.serverport=50055.
Fix: The problem according to the following scenario, in particular the problem for DTT, does not occur anymore.
Scenario for problem: The configuration variable -Dlc3.serverport can be used to set the server port for the IDE gRPC server, e.g. for the test framework, for remote-controlling the IDE or for using the device topology transformer. This is usually: 50055
If this configuration variable is not set in your environment or it is used but a different server port than 50055 is set, some features might not work as expected.
For instance, when using the sample reference implementation of the device topology transformer (DTT), the result of comparing the logic inside the DTT code generation process is the dialog Confirm for the generated models. But this dialog will not be displayed in the case of the missing configuration variable -Dlc3.serverport=50055.

The global-variables-editor might not display the expected icon for some variables.
Fix: The problem according to the following scenario does not occur anymore. According to the IDE documentation, the icon is now displayed for global variables with a user-defined data type.
Scenario for problem: The IDE documentation for the global-variables-editor contains the information that the icon is displayed for global variables with a user-defined data type. However, it also possible that a different icon is incorrectly displayed, if the variable is declared on the basis of one of the following data types:

• data type with named values (enums)

• directly derived data type

This means that the icon or  is displayed for such variables in the global-variables-editor. But only the icon should be used for this.

It might not be possible to build the application due to a called method.
Fix: It is possible to build the application for the following scenario.
Scenario for problem: If a method of a function block is called and this call is done using a global array function block instance, no errors are reported for the ST syntax. Nevertheless, the application cannot be built. In this case, the following messages are displayed:

The application for the PLC (resource "name1", platform toolkit "name2") cannot be created/loaded. Check the views "Error Log" and "Problems" for more information.

An error occurred during compiling or linking the code image (error code: 1).

After the attempt to build the application, the messages are displayed in the Problems view. Here are the messages for the customer scenario in which the problem occurred:

'LC_VD_GAUC_TESTARRAYGLOBALVAR' undeclared (first use in this function)

expected expression before 'LC_TD_FunctionBlock_APPLICATIONCOREx2EFB_TESTFB'

expected expression before 'LC_TD_FunctionBlock_APPLICATIONCOREx2EFB_TESTFB'

implicit declaration of function 'LC_GV_ACCESS_ARRAY'; did you mean 'LC_GV_ACCESS_FB'? [-Werror=implicit-function-declaration]

Undoing/Redoing the delete action for all sections does not work as expected.
Fix: The problem according to the following scenario does not occur anymore.
Scenario for problem: When you delete all sections in the global-variables-editor, but then you undo and redo this delete action, the sections are not deleted as expected.

It is not possible to build the application, if a function block variable is assigned to the ANY input of a function block.
Fix: It is possible to build the application for the following scenario. The line in the FBD-editot is not highlighted as faulty anymore.
Scenario for problem: If you declare a function block instance and you assign the appropriate function block variable to the ANY input of a function block (see the following example in ST), it is not possible to build the application.

PROGRAM MyTest

  VAR

    rs1 : rs;

  END_VAR

  SEL(IN0 := rs1); (* The input 'IN0' of 'SEL' is declared with the generic data type 'ANY'. *)

END_PROGRAM

In this case, the following messages are displayed:

Faulty source files. The application for the PLC (resource "name1", platform toolkit "name2") cannot be created/loaded. Check the views "Error Log" and "Problems" for more information.

An unexpected error occurred: File <path>\<project>\src-gen\lcpu___mytest.c is missing.

Additional information: The problem also occurs in the FBD-editor. There, the line between the value field containing the function block variable and the ANY input of the function block is highlighted as faulty. The following error message is reported by mistake for this line:

Safety conflict: The unsafe output cannot be assigned to a safe input.

An exception is caused by a wrong array initialization when creating a new structured variable via the content assist.
Fix: The problem according to the following scenario does not occur anymore.
Scenario for problem: When creating a value field with a new variable via the content assist, by mistake it is possible to enter an array initial value for a variable that is declared based on a structured data type. For instance, if you enter Var1: myStruct := 1 (where myStruct is the structured data type), the variable is created. When saving the FBD-editor, an exception is caused. In this case, the error log displays this message:

class com.logicals.lc3.api.model.st.pou.impl.ArrayConstantImpl cannot be cast to class com.logicals.lc3.api.model.st.expression.StructureConstant (com.logicals.lc3.api.model.st.pou.impl.ArrayConstantImpl and com.logicals.lc3.api.model.st.expression.StructureConstant are in unnamed module of loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @9dada78) ...

An exception is caused when initializating structure elements while creating a new structured variable in the list of the declared variables.
Fix: The problem according to the following scenario does not occur anymore.
Scenario for problem: It is not possible to create a new variable with an initial value in the list of declared variables, if the variable is declared on the basis of a structured data type. If you enter the data for the variable in the dialog (see the following example), the variable is not created, but an exception condition is caused. In this case, the message Invalid expression is displayed in the error log.
Example for the data of the variable:

• Name: Var1

• Data type: myStruct

• Initial value: (Elem1 := true)

The IDE documentation on the safety parameter editor does not contain information on the valid range for floating point value.
Fix: The online help was corrected around the middle of December 2023 to provide the missing information. The HTML help for the following versions (e.g. V3.23.2, V3.24.0) also contains this information.
Scenario for problem: The article "Viewing or changing the current parameter values" under the section "Hardware parameterization using the safety parameter editor" contains instructions on how to change values in the safety parameter editor. An example for a floating point value is specified, it illustrates the behavior that the safety parameter editor changes the specified value. But there are no generic information on the valid range for floating point values and when such values are changed.
Additional information on the floating-point values: Due to the internal representation of floating-point numbers, the safety parameter editor might round the specified floating point value as follows:

• If a single-precision floating-point number (also known as float32 value) has more than 7 digits in its fractional part, this value is rounded by the safety parameter editor to have at a maximum of 7 digits in its fractional part.

• If a double-precision floating-point number (also known as float64 value) has more than 15 digits in its fractional part, this value is rounded by the safety parameter editor to have a maximum of 15 digits in its fractional part.

Moreover, if a specified value cannot be precisely interpreted as a floating-point number, the safety parameter editor corrects the value to the corresponding floating-point number.

Example: The value 3.1415166 is rounded to 3.1415167. The reason is that 3.1415166 is represented as 3.14151668548583984375 as a floating-point number, which is finally rounded to have a 7 digit fraction.
Also observe the following:

• When you hover over the field for Value, the tooltip informs you about the type of the floating point value. The value is either Float32 or Float64.

• You are able to specify a floating point value using the exponent notation, such as 3.1415167e2. In this case, the safety parameter editor corrects the specified value to a notation without the exponent. As a consequence, the yellow background color of the changed field is kept and a warning informs you about the change. You have to e.g. press the Enter-key in order to confirm the value that has been entered by the safety parameter editor instead of your specified value.

An exception occurs during the SiL/PiL test for a library block.
Fix: The exception does not occur for the following scenario anymore.
Scenario for problem: If you execute a SiL/PiL test for a library block, this test is executed but an exceptions occurs. In this case, the error log displays the following message: java.lang.NullPointerException: Cannot invoke "String.indexOf(int)" because "fullPath" is null
Additional information: A test suite for a library block can be created by using the context menu command New.., Other... and Block Test Suite in the category for the test framework.

The fingerprint of the built application might not be updated in the "Build Log" view when the C-sources are changed.
Fix: The fingerprint of the built application is updated in the Build Log view for the following scenario.
Scenario for problem: When changing the contents of a C-file of a vendor block and saving this change, the fingerprint of the application is not updated in the Build Log view. when the application is built for the first time after the change.

Specific notations for duration literals, date and time literals and time of day literals are not supported when defining intial values for outputs in the test case.
Fix: The problem according to the following scenario does not occur anymore.
Scenario for problem: When defining an initial value for outputs in the test case, it is not possible to use the following notations:

• T# – example for such an initial value: T#14ms

• DATE# – example for such an initial value: DATE#1984-06-25

• TIME_OF_DAY# – example for such an initial value: TIME_OF_DAY#15:36:55.36

If you use this notations, the tests will be failing because the intial values are not considered as expected.

Changing the instance name does not update the referenced instance name.
Fix: The problem according to the following scenario does not occur anymore.
Scenario for problem: It is possible to use an instance name of a function block within a value field (e.g. you enter RS1.Q1 to call the output Q1 of the function block instance RS1). When you rename the instance, the instance name in the value field is not updated. Only when you save the changed FBD-editor, the Problems view displays messages that the references cannot be resolved.

When using ST data types with the SIZE/OFFSET pragma, mapping variables to IEC hardware addresses might produce wrong copy sizes and bit offsets.
Fix: The problem 1 according to the following scenario does not occur anymore. The problem 2 according to the following scenario does not occur anymore as well, but this has been fixed based on the issue with the ID “110243”
Scenario for problem 1: In the ST-editor, when you use a directly derived data type with the optional attribute SIZE for the bit size for an array variable, the result for the copy sizes and bit offsets is not as expected.
Scenario for problem 2: When you declare a structured data type in the ST-editor and you specify the optional attribute OFFSET, the pragma is ignored by the size calculation and may lead to a calculation of a wrong copy size.

The IDE documentation contains wrong information: The lower and upper limit is not correctly specified for the data type BOOL.
Fix: The IDE documentation has been corrected for the current version.
Scenario for problem: The article “Supported data types (in ST))” in the IDE documentation specifies the supported data types, their initial values, lower limits and upper limits. The lower limit and the upper limit for the data type BOOL is not correctly specified in the IDE documentation. Observe that the German and the English language of the IDE documentation contain wrong information. The following text on the lower limit and upper limit is the correct information for the data type BOOL:

The assignment to a reference variable is reported as an error by mistake.
Fix: The problem according to the following scenario does not occur anymore.
Scenario for problem: In the following ST-code, the assignment to the reference variable is reported as an error:

FUNCTION_BLOCK RefToVar

VAR

cnt : DINT;

rcnt : REF_TO DINT;

END_VAR

METHOD execute

rcnt := REF(cnt); // This is the assignment to the reference variable 'rcnt'.

END_METHOD

END_FUNCTION_BLOCK

The following error message is reported: References to local variables are not allowed in functions/methods. "cnt" is a local variable.

A wrong error about a safety conflict is reported when a function block instance is connected to the input of a SEL block.
Fix: The line is not highlighted as faulty anymore, and the safety conflict error is not reported anymore. Analogous to the ST-code, the application with the FBD-editor cannot be built (see the release notes for the ID “111534” for this problem).
Scenario for problem: When you enter a function block instance in a value field (e.g. sr1) and connect this value to the input IN1 of a SEL block, the line is highlighted as faulty and the following error is reported: Safety conflict: The unsafe output cannot be assigned to a safe input.
However, the logic does not use any element for a safety-related application. So this message regarding the safety conflict is misleading.
Compare: In the ST-editor, the analogous ST-code is not reported as faulty. However, the application cannot be built for the ST-code; see the release notes for the ID “111534” for this problem.

The application cannot be built using an external variable declared in the ST code and an input variable declared in a function block. Both variables have the same name.
Fix: The problem according to the following scenario does not occur anymore.
Scenario for problem: The application cannot be built for the following scenario:

1. The program in ST contains the declaration of an external variable (VAR_EXTERNAL … END_VAR).

2. A function block contains the declaration of an input variable (VAR_INPUT … END_VAR).

3. The external variable as well as the input variable have the same name, but different upper and lower case.

When several function blocks have been created in the same ST object, the command "Delete" in the application navigator deletes all function blocks in this ST object without any previous information.
Scenario for problem: It is possible to create several language elements, such as function blocks, in the same ST-object. When in the application navigator, you are selecting the command Delete for one of these language elements, all language elements in the ST-object are deleted because the entire ST-object is deleted. There is no information before the delete action that other elements will be affected by the delete action.
Additional information: The same problem occurs in case of a moving action. This means: If one element is moved, the other elements within the ST-object are moved as well.
Workaround: Before you delete an element, you might want to check whether there are other elements in the same object. If yes, rather delete the element in the ST-object (i.e. in the ST-editor).

The command "Go Into" in the application navigator does not behave as expected.
Scenario for problem: The command Go into should refocus the view to the currently selected folder. However, if the command is selected in the application navigator (for example, for the folder Project blocks), the view does not display the contents of only this folder, but all projects that are currently open will be displayed in that folder as well. This behavior in the application navigator is not as expected.
Workaround: none available

The automatically generated H-/C-files for vendor blocks are not automatically locked. The editor for them is not opened in a read-only mode.
Scenario for problem: If you open an existing object from within the view Team Monitor, the IDE automatically locks this object. If the IDE cannot lock the object, the editor is opened in read-only mode. This is true for a vendor block itself but not for the H-/C-files that are automatically generated for the vendor block.
Workaround: Lock the H-/C-files yourself by opening the context menu for these files within the project explorer and selecting the command Lock selected files.

Syntax errors might be caused when using the content assist to suppress warnings for rule violations.
Scenario for problem: The IDE documentation contains information to use the content assist when trying to suppress the warning for a rule violation (based on a specified example in the documentation). But when doing this, an error about an unexpected character is caused for the following 2 rules:

• Namespaces of language elements must match the identifier of the parent namespace folder.

• Namespace folders need a unique identifier.

Workaround: none existing

The changed file association is ignored for opening a data type from a library configuration.
Scenario for problem: The user preferences allow to change file associations for data types. However, if you delete the Editor for data types association assigned to the data type .iecst, the graphical enum-editor continues to be opened when opening a data type from a library configuration.
Workaround: none available

No emphasis is displayed when reconnecting existing link elements within the LD-editor.
Scenario for problem: The possible logic elements (e.g. contacts and coils) should be emphasized when reconnecting existing link elements to indicate that you can reconnect the link element to one of these logic elements. However, this emphasis is not displayed within the LD-editor.
Workaround: none existing

The "Team Monitor" view does not determine the status changes on the team server at the expected interval.
Scenario for problem: The upper list under Changed on master of the Team Monitor view shows which changes of the project are available on the team server. If the local files differ from the status of the master, this view should be updated automatically every 30 seconds. However, the list is not updated but it remains empty.
Workaround: Refresh the list yourself by selecting Refresh in the context menu for the list or by pressing the F5-key.

It is possible to turn a folder into a namespace folder and vice versa without the appropriate access control rights to edit the application logic.
Scenario for problem: Without the access right Edit application logic, it is not possible to edit the application logic. However, it is possible to:

• turn a folder into a namespace folder by selecting Assign Namespace in the context menu for a folder within the application navigator.

• remove the namespace assignment and namespaces for objects by selecting Unassign Namespace in the context menu for a namespace folder within the application navigator.

Workaround: none existing

It is possible to assign a USING instruction for accessing a namespace folder and delete this instruction without the appropriate access control rights to edit the application logic.
Scenario for problem: Without the access right Edit application logic, it is not possible to edit the application logic. However, it is possible to:

• assign a USING instruction for accessing the objects of a different namespace folder existing in the application navigator.

• delete such a USING instruction in the application navigator.

Workaround: none existing

The artifact identity is not created/updated when turning a folder into a namespace folder or assigning a USING instruction for accessing a namespace folder.
Scenario 1 for problem: The file with the artifact identity is not created, if you turn a folder into a namespace folder by selecting Assign Namespace in the context menu for a folder within the application navigator.
Scenario 2 for problem: If there is a file with the artifact identity (see "Workaround") and you assign a USING instruction for accessing a different namespace folder, the file with the artifact identity is not updated.
Additional information: The problems only occur, if you are using the feature "artifact identity". The missing/outdated file with the artifact identity is not reported to the user. The problems become only obvious if the user tries to execute an actions with the namespace folder (e.g. moving the namespace folder is not possible).
Workaround after any action regarding a namespace folder: Locate the file .iecproperties in the namespace folder. Observe that this file is hidden in the project explorer and application navigator by default. Therefore, uncheck the filter for .* resource to display the file in the project explorer. Then open the file .iecproperties in a text editor of the IDE, make a minimal change (e.g. add a blank) and save the change in order to create/update the artifact identity.

Building an application might lead to linker warnings.
Scenario for problem: Depending on the used toolchain, linker warnings might occur when building an application. The warnings are caused by a discrepancy between extern declarations and the definition of symbols in the C-code. The problem has been observed when using external variables in the ST-code or in the FBD-logic.
Workaround: Ignore the warnings.

The IDE documentation differs from the implementation in a special case for replacing a block call.
Scenario for problem: The IDE documentation describes special cases when replacing a block call. Example 1 in the section "Behavior when replacing: Instance name is not used" shows that:

1. the access to a variable of the original block is not automatically updated to the name of the new block.
   The implementation and IDE documentation match here.

2. the access is highlighted as faulty.
   The implementation and IDE documentation do not match here: Actually, the access is not highlighted as faulty. The reason for this is that the variable of the original block is no longer deleted automatically, as this has been the case in previous versions.

Here is the illustration from the IDE documentation in which the value field with the access SR1.Q1 became faulty after a block SR has been replaced by a block TON:

However, this value field will not be highlighted as faulty.
Additional information: The English IDE documentation contains a 2nd image for the example 1 that does not illustrate the replacement from SR by TON, but it repeatedly displays the 1st image with the block SR. The German IDE documentation contains the correct image of the replacement.
Workaround: none existing

Objects in nested namespace folders do not have a nested namespace.
Scenario for problem: If you create a namespace folder as a subfolder in an existing namespace folder, the objects in the subfolder are only declared in the namespace of this subfolder. However, the expectation is that the objects are declared in a nested namespace, as nested namespaces for ST-objects and FBD-objects are possible according to the IDE documentation and the IDE-documentation for the namespace folders does not contain any information whether nested namespaces are possible for nested folders.
Example: The namespace folder NS1 contains the subfolder NS2 that is also a namespace folder. The objects in the namespace folder NS2 are declared in the namespace NS2. However, the expectation is that the objects are declared in the nested namespace NS1.NS2.
Workaround: none existing

The initialization of structure elements is not possible when creating a new structured variable via the content assist.
Scenario for problem: When creating a value field with a new variable via the content assist, it is not possible to enter an initial value for a variable that is declared based on a structured data type. For instance, if you enter Var1: myStruct := (Elem1 := true) (where myStruct is the structured data type and Elem1 one of its structure elements), the message Invalid expression is displayed.
Workaround: Create the variable without the intial value. For instance, enter Var1: myStruct in the content assist. Afterwards go the the list of the delared variables, double-click the created variable to open the dialog to modify its data. In the field Initial value, enter the initial value, e.g. (Elem1 := true) for the above example.

An exception might be caused when importing an existing access rights configuration.
Scenario for problem: If an existing access rights configuration is imported into a closed project, an exception is caused. In this case, the text java.util.NoSuchElementException: No value present is displayed in the error log.
Workaround: Import the access rights configuration into the opened project.

After a failed loading of the application, GUI elements in the “Instances“ view might not be in sync.
Scenario for problem: When using a microcontroller system without a separation between firmware and application (e.g. when using Controllinos as PLCs), it is possible that some of the GUI elements in the Instances view are not correctly synchronized. The problem has been observed after an application could not be loaded onto the PLC because the application used too much RAM. The following happened after the Gateway closed the connection:

• The button Connect to PLC was enabled but the line Connection state displayed Online.

• All other information about the PLC displayed Unknown”.

Workaround: Click the button Connect to PLC again to update the state. Subsequently, the line Connection state displays Online with the execution state Error.

The integration acceptance tests cannot be executed because of missing files.
Scenario for problem: The integration acceptance tests according to the integration manual cannot be executed as expected. The reason is that files for the project LC3cSystemTest are missing. This problem applies to versions that are used to develop safety-relevant applications.
Additional information: The integration manual specifies specific integration acceptance tests which a system integrator must execute when integrating the IDE.
Workaround: Contact Neuron to get the missing files.

The build report might contain error messages about unverified data types.
Scenario for problem: The build report contains error messages about unverified data types, if the data types are only used in a C-code. Hence, the problem also applies, if the data type has been used in the ST body only, e.g. in an IF statement, or if just a temporary variable (VAR_TEMP … END_VAR) has been declared based on the data type.
The build report contains this error message:

The source file "project_path/src-gen/h/lcdt___data_type_name.h" with checksum "checksum_value" could not be verified.

Workaround: In an ST program or an ST function block, declare an internal variable (VAR … END_VAR) based on the data type.

A message is displayed when entering “**” at the beginning of a text file.
Scenario for problem: When you enter the characters “**” (but without ““) at the beginning of a text file located in the folder src and you save this text file, the following message is displayed: Unrecognized table header: ''
Additional information: The problem has been detected in a customer version.
Workaround: none existing

Deviation in the technical specification for PLCopen blocks, current version 2.10 to previous version 2.01.
Scenario for problem: The implementations of the blocks EmergencyStop, ESPE and PSE were identical in the technical specification "TC5 - Safety, Version 2.01 – Official Release, Part 1 - Concepts and Function blocks" (© PLCopen). Since version 2.10 of this technical specification, the implementation of EmergencyStop does not follow the others blocks anymore.
Neuron assumes that this is wrong in the technical specification and is currently clarifying this with PLCopen.
Workaround: none existing

• an item for a ZIP-file

• an item named "folderName"

Workaround: none existing

1. Have the “Values of Variables” view displayed.

2. Move the view to the right of the error logger.

3. Bring the error logger to the front.

4. Close and restart the IDE with the same workspace.
   Result: The “Values of Variables” view is still provided right of the error logger.

5. Switch to the “Instances” view, expand the tree until a variable is displayed, open the context menu for this variable and select “Add Variable to Values of Variables”.

Workaround: none existing